This seems inefficient as we're querying SQLite for rows read/written counts on every single row just in case the database is later resent before the query is destroyed -- which is very rare.

Instead, how about putting code into Query::beforeSqliteReset() that posts the metrics early (calls addQueryStats directly), and then have the destructor only post metrics if it hasn't been reset (i.e. maybeStatement is non-null).

I did try that approach first. The problem with that comes in the way we do getRowsRead() and the way the Statement and Query are setup. There are a couple of corner cases that have to be handled - when the Query has its own statement vs passed in a statement, handling the beforeSqliteReset in both Query and Statement.
In the end, I decided to go this route as it is easy to reason about.

As far as inefficiency in querying Sqlite for rows read/written, looking at the implementation of getRowsRead/Written, it does a sqlite3_stmt_status(...) which does a pointer read, so its not as inefficient as we think it is

I added a todo with more details